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ABSTRACT 

US  Joint  Forces  Command's  (USJFCOM)  Joint  National  Training  Capability  (JNTC)  program  has  been 
tasked  by  the  Office  of  the  Under  Secretary  of  Defense  (OUSD)  for  Personnel  and  Readiness  (P&R)  to 
develop  and  integrate  a  distributed,  seamless  Joint  Training  Environment  (JTE)  consisting  of  Live, 
Virtual,  and  Constructive  (JVC)  training  technologies.  Currently,  LVC  assets  within  the  JNTC 
architecture  are  integrated  through  loosely  defined  protocols,  multiple  types  and  instances  of  protocol 
translators,  and  a  collection  of  distributed  messaging  tools,  most  of  which  are  either  ill-defined,  require 
technical  expertise  to  use,  or  do  not  provide  the  level  of  interoperability  necessary  to  meet  OUSD  P&R 
requirements.  The  Joint  Training  and  Education  Capability  Group  (JTECG)  is  studying  future  LVC 
integration  concepts  and  tools  that  will  address  these  limitations  and  result  in  more  interoperable  LVC 
systems.  One  such  tool,  the  Joint  LVC  Data  Translator  (JLVCDT)  Framework,  will  reduce  the  number 
and  variety  of  protocol  translators  used  to  support  Joint  training,  will  support  rapid  development  and 
integration  of  LVC  protocols  through  the  use  of  a  scalable  software  architecture,  and  will  act  as  a  system 
and  software  platform  for  further  research  and  development  of  a  Common  LVC  Architecture  (CLA). 
Developed  in  conjunction  with  the  United  States  Services,  the  JLVCDT  will  reuse  software  and  interfaces 
from  existing  Service  and  Joint  tools  within  a  more  scalable  and  extensible  application  infrastructure. 
The  JLVCDT  will  be  easier  to  configure,  deploy,  and  control  than  existing  tools  and  will  require  less 
technical  expertise  to  operate.  It  is  anticipated  that  development  of  the  JLVCDT  will  continue  through 
2007  resulting  in  an  initial  operating  capability  that  can  be  used  to  support  JNTC  events  (including  multi¬ 
national  partnersjby  late  2007to  early  2008.  This  paper  will  describe  the  vision  for  the  JLVCDT,  the 
technical  approach  to  developing  the  JLVCDT,  and  how  the  JLVCDT  supports  the  CLA  concept. 


1.0  INTRODUCTION 

The  Department  of  Defense  (DoD)  Training  Transformation  (T2)  program  has  identified  three  key 
capabilities  designed  to  prepare  Joint  and  Service  personnel  in  Joint  operations  as  part  of  the  future 
warfighting  environment:  Joint  Knowledge  Development  and  Distribution  Capability  (JKDDC),  JNTC, 
and  Joint  Assessment  and  Enabling  Capability  (JAEC).  JKDDC  focuses  on  individual  training,  JNTC 
focuses  on  collective  training,  and  JAEC  assesses  the  validity  of  both  individual  and  collective  training 
against  Joint  requirements.  The  combination  of  these  capabilities  will  ensure  that  combatant  commander 
forces  are  constantly  evolving  in  order  to  achieve  a  higher  level  of  Joint  force  readiness. 


Bizub,  W.;  Bryan,  D.;  Harvey,  E.  (2006)  The  Joint  Live  Virtual  Constructive  Data  Translator  Framework  -  Interoperability  for  a  Seamless 
Joint  Training  Environment.  In  Transforming  Training  and  Experimentation  through  Modelling  and  Simulation  (pp.  9-1  -  9-8).  Meeting 
Proceedings  RTO-MP-MSG-045,  Paper  9.  Neuilly-sur-Seine,  France:  RTO.  Available  from:  http://www.rto.nato.int/abstracts.asp. 
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ORGANIZATION 


The  T2  Implementation  Plan  (T2-I  Plan)  provides  guidance  to  JKDDC,  JNTC,  and  JAEC  on  how  to 
transform  current  forces  to  support  future  Joint  operations.  JNTC,  the  focus  of  this  paper,  is  instructed  to 
“prepare  forces  by  providing  units  and  command  staffs  with  an  integrated  live,  virtual,  and  constructive 
training  environment  with  appropriate  joint  context  that  allows  accurate,  timely,  and  relevant  training  in 
support  of  specific  operational  needs  [1].”  This  statement  suggests  that  an  integrated  Live,  Virtual,  and 
Constructive  (LVC)  training  environment  is  a  key  enabler  in  achieving  the  JNTC  mission.  As  such,  the 
JNTC  Technical  Management  team  has  been  investigating,  enhancing,  and  developing  both  current  and 
future  technologies  to  provide  an  integrated,  seamless,  and  interoperable  LVC  training  environment. 


2.0  CURRENT  CAPABILITIES 

Currently,  JNTC  events  use  multiple  types  and  instances  of  protocol  translators  to  integrate  the  necessary 
LVC  assets.  Examples  of  these  interfaces  include  High  Level  Architecture  (HLA),  Distributed  Interactive 
Simulation  (DIS),  Test  and  Training  Enabling  Architecture  (TENA),  Tactical  Data  Links  (TADIL), 
Command,  Control,  Communications,  Computers  and  Intelligence  (C4I),  and  digital  and  analog  voice 
interfaces,  among  others.  The  majority  of  these  interfaces  are  developed  by  different  vendors,  utilize 
different  techniques  for  achieving  their  functions,  and  require  technical  subject  matter  experts  to  install, 
configure,  test,  operate,  and  maintain. 

Table  1:  JVTSE  Gateway  Plan 


Translator 

Types 

#of 

Protocols 

#  of 

Instances 

#  of 

Operators 

w/o 

JLVCDT 

13 

40 

28 

~10 

w/ 

JLVCDT 

(near- 

term) 

3 

40 

8 

~4 

w/ 

JLVCDT 

(long¬ 

term) 

1 

40 

5 

~2 

Table  1  provides  a  summary  of  the  2005  Joint  Virtual  Training  Special  Event  (JVTSE)  gateway  plan.  The 
summary  table  includes  high-level  statistics  of  the  gateway  resources  required  to  conduct  the  event  both 
with  and  without  a  JLVCDT-like  capability.  Both  near-term  and  long-term  goals  are  listed  for  the 
JLVCDT  capability.  It  is  anticipated  that  this  capability  can  significantly  reduce  the  operations  and 
maintenance  costs  required  to  integrate  and  employ  LVC  environments.  The  larger  or  more  complex  the 
LVC  environment  becomes,  the  greater  the  expected  benefit.  To  meet  this  need,  the  JTECG  Technical 
Management  Team,  in  conjunction  with  the  Services,  is  developing  the  JLVCDT  Lramework. 


3.0  JLVCDT  OVERVIEW 

The  JLVCDT  will  reduce  the  number  and  complexity  of  translators  used  in  the  JTE  through  the 
development  and  employment  of  an  extensible  translator  framework.  The  Lramework  will  provide  a 
system  and  software  architecture  capable  of  rapidly  integrating,  configuring,  controlling,  and  monitoring 
the  execution  of  LVC  Interface  Modules  (LIMs). 

The  JLVCDT  Lramework  will  be  capable  of  being  employed  in  several  different  operating  modes  and 
configurations.  Examples  of  operating  modes  include  the  following: 
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1 .  Translation  Only  -  The  Translation  Only  mode  provides  protocol  translation  features  only.  This 
mode  will  be  used  most  often  when  employing  a  remote  JLVCDT  instance  or  when  translation 
performance  has  been  determined  to  be  a  priority. 

2.  Graphic  User  Interface  (GUI)  Only  -  The  GUI  Only  mode  provides  configuration,  monitoring, 
and  control  of  one  or  more  JLVCDTs.  Translations  to/from  LVC  protocols  do  not  occur  in  this  mode. 

3.  Translation/GUI  Combination  -  If  desirable,  the  Translation  and  the  GUI  can  be  initialized  as  part 
of  the  same  process.  This  mode  contains  all  features  described  in  the  Translation  Only  and  GUI  Only 
operating  modes. 

Examples  of  configurations  include  the  following: 

1.  One-to-One  -  Similar  to  currently  employed  translator  capabilities,  the  JLVCDT  will  be  capable 
of  translating  bi-directional,  one-to-one  LVC  protocols  (e.g.,  HLA  <->  DIS). 

2.  One-to-Many  -  The  JLVCDT  will  be  capable  of  translating  bi-directional,  one-to-many  LVC 
protocols  (e.g.,  HLA  <->  DIS/Link). 

3.  Many  to  Many  -  The  JLVCDT  will  be  capable  of  translating  bi-directional,  many-to-many  LVC 
protocols  (e.g.,  HLA/TENA  <->  DIS/Link). 

Additional  configurations  of  one  or  more  JLVCDT  instances  may  be  required  in  order  to  support  specific 
hardware  interfaces,  network  interfaces,  and  performance  requirements.  In  these  cases  it  will  be  possible 
for  communication  to  occur  between  JLVCDT  instances. 

JLVCDT  operators  will  have  the  ability  to  instantiate,  configure,  control,  and  monitor  the  execution  and 
performance  of  one  or  more  JLVCDT  instances  through  the  GUI  on  a  distributed  network.  The  GUI 
design  will  be  based  on  well-understood  human-computer  interface  principles  in  order  to  reduce  the  need 
for  engineering-level  support.  In  addition,  the  GUI  will  provide  a  set  of  tools  and  interfaces  that  support 
the  test,  integration,  debugging,  and  run-time  performance  monitoring  and  control  of  LIMs  [1]. 

3.1  Management  Strategy 

The  JLVCDT  project  began  in  Fiscal  Year  (FY)  2005  and  initially  focused  on  requirements  specification, 
the  identification  of  reuse  opportunities,  and  high-level  design.  In  addition,  JLVCDT  goals  and  objectives 
were  briefed  to  the  Joint  community  (via  JNTC)  to  ensure  that  the  Services  were  supportive  of  the 
JLVCDT  concept  and  to  maximize  reuse  opportunities.  Reuse  of  existing  translators  within  the  JLVCDT 
Framework  is  a  key  component  of  the  JLVCDT  management  strategy.  Acting  as  the  lead  for  JLVCDT, 
the  technical  managers  have  provided  initial  feedback  on  requirements,  design,  and  development  priorities 
to  the  implementation  team. 

JNTC’s  current  operations  technical  integration  group  has  requested  a  near-term  JLVCDT  capability  that 
will  provide  two-way  HLA  to  DIS  connectivity  in  support  of  JNTC  events.  The  technical  integration 
group  currently  employs  multiple  instances  of  these  gateways  to  support  interoperability  between  the 
Services’  virtual  and  constructive  simulation  systems.  The  JLVCDT  is  intended  to  provide  equal  or  better 
functional  capabilities  than  current  translators,  but  in  a  more  common,  usable  and  open  software 
architecture. 

Additional  FY06  JLVCDT  goals  include  initial  implementations  of  TENA,  TADIL,  and  C4I  LIMs,  as 
well  as  core  architecture  development.  Of  particular  significance  is  the  development  of  a  C4I  LIM  that  is 
capable  of  reducing  redundancies  in  LVC-generated  Common  Operating  Pictures  (COP)  such  as  the 
Global  Command  and  Control  System  (GCCS).  These  redundancies  are  a  result  of  legacy  simulation 
systems  not  adhering  to  the  6016C  Link- 16  military  standard.  The  JLVCDT  will  be  capable  of  translating 
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the  non-compliant  messages  into  compliant  messages  for  a  lower  effort  and  cost  than  would  be  required  to 
upgrade  the  legacy  simulations.  In  addition,  the  JLVCDT  Link- 16  capabilities  will  allow  other  Link- 16 
systems  to  participate  in  the  JTE  and  it  will  provide  Theater  Ballistic  Missile  (TBM)  and  space  reporting 
for  applicable  platforms. 

Anticipated  long-term  JLVCDT  goals  include  the  development  of  a  GUI  that  supports  configuration  and 
control  of  remote  JLVCDT  instances,  the  publication  of  an  Application  Programmer’s  Interface  (API)  that 
will  allow  any  organization  to  develop  LIMs,  and  the  development  of  custom  LIMs  to  support  program- 
specific  LVC  interfaces.  Prioritization  of  long-term  JLVCDT  goals  and  objectives  will  occur  each  Fiscal 
Year. 


4.0  JLVCDT  DESIGN 

The  JLVCDT  system  and  software  architecture  is  open  and  extensible.  One  benefit  of  this  approach  is 
that  other  organizations  will  be  able  to  enhance  existing  LIMs  or  develop  new  LIMs.  This  design  feature 
will  help  ensure  that  the  JLVCDT  will  support  as  many  Joint  and  Service  users  as  possible. 

LVC  Interface  Modules 


Framework 

Manager 


Mapping  Tool 


Configuration  & 
Control  Tool 


Monitoring  Tool 


Core 

API 


Framework 


Common  Data 
Definition 


Conversion 

Functions 


Module 

API 


Constructive 
Translation 
Module  (0..N) 

Live  Translation 
Module  (0..N) 

Virtual  Translation 
Module  (0..N) 

JLVCDT 

Communication 

Module 

Figure  1:  JLVCDT  Component  Architecture 


Figure  1  depicts  the  component  architecture  of  the  JLVCDT  Framework.  The  primary  components  of  the 
JLVCDT  Framework  are  the  following  [2]: 

1.  Framework  Manager  (FM)  -  A  set  of  Graphical  User  Interface  (GUI)  tools  that  support  the 
configuration,  control,  and  deployment  of  the  JLVCDT  Framework. 

a.  Mapping  Tool  -  Maps  data  elements  between  protocols 

b.  Configuration  and  Control  Tool  -  Sets  system  and  application  parameters  and  controls 
run-time  performance 

c.  Monitoring  Tool  -  Provides  feedback  on  system,  application,  and  network  performance 
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2.  Framework  -  The  core  of  the  JLVCDT  system  responsible  for  managing  and  mapping  LIM  data. 

a.  Core  API  -  The  API  used  to  integrate  the  Framework  into  other  applications  (e.g.,  the 

FM) 

b.  Module  API  -  The  API  used  to  integrate  LIMs  into  the  Framework 

c.  Configuration  Manager  -  The  component  responsible  for  LIM  configuration  and 
instantiation. 


d.  Data  Manager  -  The  component  that  passes  data  between  the  Framework  Core  and  the 
Module  API/LIMs. 


e.  Conversion  Functions  -  Common  functions  used  to  convert  data  and  data  types  between 
protocols 

f.  Common  Data  Definition  -  The  integrated  data  model  that  facilitates  all  data  use,  storage, 
and  translation. 

3.  LVC  Interface  Modules  (LIMs)  -  One  or  more  instantiations  of  LVC  interfaces. 


4.1  LVC  Interface  Modules 

New  or  existing  LIMs  may  be  integrated  into  the  Framework.  The  determination  of  whether  to  use  an 
existing  LIM  or  develop  a  new  LIM  will  be  based  on  a  combination  of  management  and  technical  criteria 
including,  but  not  limited  to,  time  and  effort  required,  technical  risk,  capabilities  and  limitations, 
extensibility,  complexity,  and  maintainability. 

Each  translation  LIM  will  provide  basic  services  for  its  protocol  including  registering  subscriptions, 
receiving  data  from  its  network  interface  and  providing  it  to  the  Framework  through  the  Module  API,  and 
packing  and  sending  outgoing  messages  [2]. 

In  addition  to  translation  LIMs,  the  JLVCDT  will  also  support  application  LIMs.  The  basic  services  and 
responsibilities  for  application  LIMs  are  similar  to  those  of  translation  LIMs.  The  primary  differences 
being  that  the  data  passed  from  an  application  LIM  into  the  Framework  is  not  read  from  a  network 
interface  and  no  data  received  by  an  application  LIM  from  the  Framework  is  sent  out  via  a  network 
interface.  Any  application  that  needs  access  to  the  data  being  translated  would  be  a  candidate  application 
LIM  (e.g.,  a  dead  reckoning  module,  a  logger,  etc.). 

Each  LIM  will  subscribe  to  data  and  events  through  an  observer  interface.  When  a  message  or  data  set 
that  the  LIM  is  subscribed  to  comes  into  the  Framework  from  any  other  LIM,  the  interested  LIM  will  be 
notified  so  that  it  may  process  that  message  or  data  set  appropriately.  Each  LIM  will  run  in  its  own  thread 
to  avoid  blocking  the  Framework  as  a  result  of  network  operations  and  data  processing.  If  desired,  any 
LIM  could  be  separated  its  own  process,  e.g.,  to  distribute  LIMs  onto  other  machines  or  to  avoid 
namespace  collisions  within  LIM  protocol  libraries. 


4.2  Technical  Benefits 

In  addition  to  the  high-level,  conceptual  benefits  of  the  JLVCDT  system  presented  earlier  in  the  paper, 
there  are  several  low-level,  technical  benefits  to  the  JLVCDT  implementation  worth  noting.  First,  through 
the  use  of  threading  and  a  well-defined  software  infrastructure,  the  JLVCDT  will  support  many-to-many 
translations.  This  capability  will  reduce  the  number  of  translators,  operators,  and  computers  required  and 
will  simplify  the  system  and  networking  architectures  of  the  environments  where  the  JLVCDT  is  used. 
Next,  through  the  use  of  the  JLVCDT  mapping  tool,  data  mappings  for  each  protocol  will  be  exposed  to 
JLVCDT  users  rather  than  being  hidden  in  source  code.  In  addition  to  the  test,  integration,  and  debugging 
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benefits  of  this  feature,  this  allows  most  mapping  updates  between  protocols  to  be  made  by  JLVCDT 
operators,  rather  than  developers.  This  capability  will  reduce  the  time  and  level  of  expertise  required  to 
integrate  and  verify  distributed  LVC  environments. 

Perhaps  the  largest  benefit  of  the  JLVCDT  implementation  is  the  use  of  the  Common  Data  Definition 
(CDD).  The  use  of  a  CDD  is  desirable  because  it  hides  unimportant  (and  many  times  complex)  internal 
details  of  LIMs,  while  simultaneously  exposing  their  capabilities  to  other  LIMs.  Therefore,  in  order  to 
integrate  a  new  LIM,  a  developer  need  only  have  expertise  in  his  or  her  LIM  and  how  it  maps  to  the  CDD. 
This  approach  removes  the  requirement  for  a  LIM  developer  to  have  detailed  knowledge  of  other  LIM 
data  elements  and  mappings  and  allows  rapid  construction  of  many-to-many  translators. 

In  addition  to  the  technical  benefits  described  above,  the  JLVCDT  Framework  will  be  developed  using 
modem  tools  and  techniques  that  will  result  in  a  stable,  extensible,  and  usable  system  and  software 
implementation.  These  benefits  may  not  be  as  quantifiable  as  some  of  the  others  mentioned  above  but 
they  are  no  less  significant. 
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Figure  2:  Common  LVC  Architecture  Vision 


5.0  COMMON  LVC  ARCHITECTURE 

The  JLVCDT  will  support  the  transition  and  transformation  from  JNTC  initial  operating  capability  to  final 
operating  capability.  However,  the  implementation  of  the  JLVCDT  should  not  and  will  not  preclude 
further  research  and  development  of  integrated  LVC  concepts.  Examples  of  additional  integrated  LVC 
concepts  that  the  JTECG  technical  managers  are  currently  investigating  include  extensible  Battle 
Management  Language  (XBML),  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM/JC3IEDM),  Global  Information  Grid  (GIG)  and  GIG  Net-Centric  Enterprise  Services  (NCES), 
web  services,  and  others.  Some  of  these  concepts  will  increase  the  interoperability  of  data  between 
systems  while  others  will  increase  the  availability  of  data.  In  either  case,  a  higher  level  of  interoperability 
between  LVC  systems  is  possible  in  the  form  of  a  Common  LVC  Architecture  (CLA)  as  depicted  in 
Figure  2. 
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A  CLA  will  move  beyond  on-the-wire  interoperability  towards  semantic  interoperability  and  will  be 
supported  by  on  demand  networks  and  services.  One  of  the  key  tenets  of  semantic  interoperability  is  that 
data  is  not  only  defined,  but  is  comprehended  by  all  systems  that  need  to  use  it.  The  responsibility  of  data 
comprehension  is  shared  between  the  data  and  the  system,  rather  than  with  the  system  and  the  system 
developer.  Transitioning  to  a  CLA  implementation  will  not  be  easy  or  inexpensive  but  it  is  something  that 
must  be  investigated  in  order  to  adequately  support  JNTC  T2  goals  and  objectives. 

The  JLVCDT  is  being  designed  to  meet  current  LVC  interoperability  goals  and  those  of  anticipated  future 
transitional  capabilities.  Through  the  use  of  its  mapping  tools  and  CDD,  the  JLVCDT  is  exposing  the 
details  of  LVC  interoperability  to  a  larger  audience.  As  additional  LIMs  are  added  to  the  JLVCDT,  the 
CDD  will  expand,  as  will  the  mappings,  the  conversions,  and  the  rules  for  using  that  data.  Collectively, 
this  information  is  defining  the  comprehension  associated  with  the  data  that  is  currently  hidden  in  the 
numerous  types  and  instances  of  translators  used  in  the  JTE.  Furthermore,  developers  will  be  able  to  use 
the  JLVCDT  to  add  LIMs  in  support  of  the  CLA  concept  (e.g.,  C2IEDM).  For  these  reasons,  we  believe 
that  the  JLVCDT  is  an  excellent  tool  for  defining,  experimenting,  and  testing  concepts  in  support  of  a 
CLA  construct. 


6.0  REFERENCES 

[1]  OUSD  P&R,  Director,  Readiness  and  Training  Policy  and  Programs  (2005),  “DoD  Training 
Transformation  Implementation  Plan.” 

[2]  Bogedain,  Jerry;  Mobley,  Ken;  and  Teer,  Brian  (2005),  “JLVCDT  Architecture  Description 
Document.” 
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JFCOM  Training  Audiences 


USJFCOM  JWFC  conducts  training 
for  combatant  commanders,  joint  task 
forces,  and  functional  component 
battle  staffs. 


(http://www.jwfc.jf com.  mil/) 


The  Joint  National  Training  Capability 
...  will  provide  training  to  the  full 
complement  of  defense  audiences. 
...[and]  will  evolve  to  encompass  a 
larger  training  audience,  including 
coalition  partners  and  Federal,  state, 
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agencies.  (DoD  Training  Transformation  Implementation  Plan) 
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Live  Virtual  Constructive 
Synthetic  Environment 


Live/Reai  World  C2 


Constructive 

Forces 


Virtual  Simulators 
Simulations 


The  acquisition,  testing,  training,  analysis  and  experimentation 
communities  require  rapidly-composable,  distributed  LVC  environments 
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The  LVC  Architecture  Issue 


•  Interoperability  among  LVC  entities  is  essential.  Current  LVC 
environments,  however,  are  not  inherently  interoperable. 

-  High  Level  Architecture  (HLA)  and  Distributed  Interactive  Simulation  (DIS)  are 
most  often  used  for  integrating  virtual  and  constructive  assets, 

-  Test  &  Training  Enabling  Architecture  (TENA)  is  widely  used  in  testing  and  to 
integrate  live  assets  into  exercises/events. 

-  Also,  Common  Training  Instrumentation  Architecture  (CTIA)  leverages 
commonality  among  the  U.S.  Army's  instrumented  ranges  and  home  stations; 
LVC  -  Integrated  Architecture  (LVC-IA)  is  a  multi-echelon,  integrated,  joint, 
training  and  mission  rehearsal  environment;  and  others  (e.g.  ALSP) 

•  Multiple  protocols,  gateways,  and  object  models  are  often 
used  to  bring  an  LVC  Environment  together. 

-  Interoperability  and  efficiency  issues  arise  bringing  disparate  protocols  and 
entities  together  in  a  common  operational  environment. 

-  Complexity,  disconnects,  duplication  of  effort,  risk,  and  costs  increase  with 
multiple  architectures. 


Communities  agree  that  we  need  to  achieve 
efficient  and  effective  interoperability. 
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LVC  Architecture  Evolution  ? 


A  notional  concept  that  allows  for  the  exploration  and  experimentation  of 
higher  levels  of  interoperability  between  LVC  systems 
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TEN  A  -  Test  &  Training  Enabling  Architecture 
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DIS  -  Distributed  Interactive  Simulation 
ALSP  -  Aggregate  Level  Simulation  Protocol 
SPP  -  Scalable  Parallel  Processing 
HPC  -  High  Performance  Computing 
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Requirements  Overview 


•  Reduce  the  number  of  disparate  interfaces 

•  Support  multiple,  concurrent  (a.k.a.,  many  to  many) 
translations 

•  Support  “plug  and  play”  interface  compatibility 

•  Match  or  exceed  current  translation  capability 
(throughput  and  functionality) 

•  Support  user  extension  through  a  public  API 

•  Free  distribution  with  no  licenses  or  proprietary 
components 

•  Enable  distributed  monitoring,  configuration,  and 
control  via  a  centralized,  intuitive  Graphical  User 
Interface  (GUI)  to  reduce  operator  requirements 
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The  Services  and  the  Joint  community  currently  use  multiple  types, 
instances  and  implementations  of  LVC  interfaces  to  support 
interoperability  among  disparate  architectures  and  systems 

•  Increases  the  total  cost  to  conduct  an  event  in  the  LVC  environment 

JLVCDT  is  designed  to  enhance  the  Joint  training  architecture  and 
reduce  overall  costs  by  providing  a  certified  framework  and 
promoting  interoperability  and  reuse  of  LVC  interface  components 
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v  The  JLVCDT  is 


V  The  JLVCDT  is  not 


>  A  system  and  software  architecture 

>  A  framework  for  integrating 
protocol  modules 

>  An  LVC  integration  tool 

>  Currently  a  prototype 

>  A  platform  for  investigating  future 
LVC  integration  concepts 


>  A  standard 

>  A  one  size  fits  all  solution 

>  An  attempt  to  make  existing 
translation  tools  obsolete 
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JLVCDT  Description 


•  JLVCDT  will  improve  Multi-Service  LVC 
component  interoperability 

•  The  effort  will  leverage  Government-off-the-shelf 
(GOTS)  and  Commercial  (non-proprietary) 
gateway  applications 

•  JLVCDT  will  deliver  an  open  architecture  via  a 
Dublic  API  to  encourage  broad  adoption  in  existing 
_VC  environments 

•  JLVCDT  and  its  plug-in  modules  will  be  JFCOM- 
certified  in  the  Joint  Advanced  Training 
Technology  Laboratory  (JATTL) 
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Component  Reuse 


•  Reuse  existing  components  where  possible  and 
feasible 

-  Where  reuse  saves  time,  reduces  effort,  furthers  project 
goals 

•  Consider  reuse  of  data  models,  Uls,  network 
communications,  gateways 

•  Realistic  reuse  for  gateways  includes 

-  Network  interface  layer 

-  Data  packing/unpacking  layer  (becomes  less  feasible  as 
the  core  architecture  matures) 


UNCLASSIFIED 


10 


USJFCOM 


Architecture  Overview 

•  Core  translates  to/from  a  central  data  repository  to  accomplish 
multiple,  concurrent  translations  efficiently 

•  Common  data  definition 

•  Defined  architectural  boundaries 

•  Primary  coding  effort  for  a  new  data  translation  plug-in  (reuse  or 
custom)  is  the  network  interface  layer  and  new  data  conversions 

-  Examples  will  be  available 

•  Java-based  core  for  efficiency 

-  Large-scale  object  management 

-  Multi-threaded  processing 

-  Uses  Java  Plug-in  Framework  (JPF) 

•  Java  and  C++  bindings  will  be  available 
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High-Level  Design 
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Concept  of  Operations 


Operating  Modes 

•  Translation  only 

•  GUI  only 

•  GUI  &  Translation 


Configurations 

•  One  to  one 

•  One  to  many 

•  Many  to  many 
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Name 

Protocol(s) 

Owner 

Users 

#  Instances 

#  Operators 

C4I  Gateway 

OTH  Gold,  USMTF,  HLA  PKG-11 

NWDC 

Navy 

1 

1 

DIS  Filter 

DIS 

DMOC 

1 

1 

DMON  Portal 

DIS,  HLA 

Northrop  Grumman 

DMON  sites  (USAF) 

1 

Gateway  Builder 

TENA  DIS,  Inet 

ONR 

PMRF 

1 

GOTH 

HLATENA 

NAVAIR  R  Mugu 

JNTC 

1 

1 

HLA/DIS  Gateway 

HLADIS,BFTT,SIGS 

J9 

J9,  JNTC,  Navy 

16 

1 

JDT 

BDS,  BIE,  BIG,  CJ2PC,  Cobra 

Brass,  EOBSREP,  GPS,  GTIMF, 

HR,  JQUAD,  MERIT,  OILSTOCK, 
OTH  Gold,  POSM,  RECCEXREIk 
SACM,  TAB-37,  TACELINLT  \ 
TACREP,  TDDS,  T/U^TmU, 
TDIMF,  Town  Crie/sSID-|IO,^ 
USSID-350^.  VJ 

AIA(USAF) 

AA  SOCOM, 

IBSSO,  JFCOM 
(JMPRO) 

1 

1 

LVC  Data  Translator 

OTH-Gold, 

1 1  ,TADILJ(SI*JJADILJ(MTC) 

JFCOM 

JFCOM  (JATTTL,  J9) 

1 

1 

MLST3  Interface 

TADILJ(MLST3) 

NWDC 

Navy 

1 

<1 

NT  C  Gateway 

NTC  Range,  TENA 

NT  C 

Underdevelopment 

1 

1 

SCORE-TENA  Gateway 

SCORE  Range,  TENA 

NRL 

JNTC 

1 

<1 

SIMPLE 

DIS, HLA  OTH-GOLD,  TADILJ 
(MFC) 

JNTC,  Amy  (DBST) 

1 

1 

Tostada 

DIS, TENA 

NAVAIR  R  Mugu 

JNTC 

1 

1 

13  Data  Translator  Type 

40  Protocols 

10  Owners 

12+  Users 

28  Instances 

~10  Operators 

Name 

Protocol(s) 

Contributor/Owner 

Users 

Instance 

#  Operators 

JLVCDT 

OTH  Gold,  USMTF,  HLA,  PKG-11 

NWDC 

Navy 

JLVCDT  1 

1-2 

JLVCDT 

DIS 

DMOC 

JLVCDT  2 

JLVCDT 

DIS,  HLA 

Northrop  Grumman 

DMON  sites  (USAF) 

JLVCDT  2 

Gateway  Builder 

TENA,  DIS,  Inet 

ONR 

mpiF 

GWB  1,2, 3, 4 

0-1 

JLVCDT 

HLATENA 

NAVAIR  Pt  Mugu 

jN\y 

► 

JLVCDT  3 

JLVCDT 

HLADIS,BFTT,SIGS 

J9  v  UPWTy,  Navy 

JLVCDT  2 

JDT 

BDS,  BIE,  BIG,  CJ2PC,  Cobra 

Brass,  EOBSREP,  GPS,  GTIMF, 

HR,  JQUAD,  MERIT,  OILSTOCK, 
OTH  Gold,  POSM,  RECCEXREf^ 
SACM,  TAB-37,  TACELIN^C 
TACREP,  TDDS,  T^b^ADl^ 
TDIMF,  Town  Crier|)SSID\o, 
USSID-350  V\^/ 

F 

AIA(USAF) 

i 

AA  SOCOM, 

IBSSO,  JFCOM 
(JMPRO) 

JDT  1 

1 

JLVCDT 

OTH-Goidfci  ag^G 
11,TADILJ(Slk),TADILJ(MrC) 

JFCOM 

JFCOM  (JATTTL,  J9) 

JLVCDT  1 

JLVCDT 

TADILJ(MLST3) 

NWDC 

Navy 

JLVCDT  1 

JLVCDT 

NTC  Range,  TENA 

NTC 

Underdevelopment 

JLVCDT  3 

JLVCDT 

SCORE  Range,  TENA 

NRL 

JNTC 

JLVCDT 3 

JLVCDT 

DIS, HLA  OTH-GOLD,  TADILJ 
(MFC) 

JNTC,  Amy  (DBST) 

JLVCDT  1 

Gateway  Builder 

DIS, TENA 

NAVAIR  R  Mugu 

JNTC 

GWB  1,2 

3  Data  Translator  Type 

40  Protocols 

10  Contributors/Owner 

12+  Users 

8  Instances 

2-4  Operators 
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Current  Performance 


•  JATTL  testing  shows  that  JLVCDT  performance 
compares  favorably  to  the  JNTC  HLA/DIS  gateway, 
which  is  viewed  as  a  strong  performing  gateway 

-  JLVCDT  translates  messages  at  the  same  rate  (up  to  4,000 
HLA  to  DIS  messages  per  second) 

-  JLVCDT  CPU  usage  is  lower 

-  JLVCDT  memory  usage  is  lower 

-  JLVCDT  can  handle  higher  entity  counts  (i.e.,  higher  than  the 
JNTC  HLA/DIS  gateway’s  maximum) 

•  Should  be  able  to  collect  performance  data  on  how 
TENA  plug-in  compares  to  other  TENA  gateway 
applications  (e.g.,  Goth)  in  the  near  future 
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Where  Are  We  and  What’s  Next? 


•  2006 

-  Plug-ins 

•  TENA  plug-in  testing  ongoing 

•  Link  16  plug-in  development  ongoing 

•  GCCS  and/or  AFATDS  plug-in  development  next 

-  Advanced  feature  development 

•  Complete  initial  version  of  public  C++  API 

•  Add  remote  configuration,  control,  and  monitoring  of  JLVCDT  instances 

-  General  improvements  to  framework  &  GUI 

-  Establish  process  for  seeking  &  incorporating  user  feedback 

-  Documentation  updates 

-  Prototype  Test  &  Evaluation 

•  SimTecT  2006 

•  NATO  MSG-027  Portland  Experiment 

•  USJFCOM  J9  Urban  Resolve  2015  (components) 

•  Emerald  Warrior  07-1 

•  2007 
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General  improvements  to  framework  &  GUI 
Plug-ins  (e.g.,  TADIL,  GCCS,  AFATDS) 

Advanced  feature  development 
HLA/DIS/TENA  refinement 

Testing  &  integration  in  multiple  training  environments 
Documentation  updates 


USJFCOM 

Data  Translation  Future  Needs 

•  A  translator  capability  that  is: 

-  Open  architecture  and  government-owned 

-  Supported  by  the  Joint  community  and  the  Services 

-  Cost  effective 

•  A  translator  architecture  that  is: 

-  Scalable  -  Based  on  hardware,  software,  and  network 
performance  requirements 

-  Extensible  -  Can  be  easily  adapted  based  on  dynamic 
requirements  and  protocol  specifications 

-  Easy  to  configure  and  use  -  Comes  with  a  distributed,  intuitive 
Graphical  User  Interface  that  provides  insight  into  hardware, 
software,  and  network  configuration  and  performance 
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Questions? 
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